mirror of
				https://github.com/SectorLabs/django-localized-fields.git
				synced 2025-10-30 18:48:56 +03:00 
			
		
		
		
	Update REAMDE on back-end changes
This commit is contained in:
		
							
								
								
									
										26
									
								
								README.rst
									
									
									
									
									
								
							
							
						
						
									
										26
									
								
								README.rst
									
									
									
									
									
								
							| @@ -35,14 +35,14 @@ Installation | ||||
|             'localized_fields' | ||||
|         ] | ||||
|  | ||||
| 3. Set the database engine to ``localized_fields.db_backend``: | ||||
| 3. Set the database engine to ``psqlextra.backend``: | ||||
|  | ||||
|     .. code-block:: python | ||||
|  | ||||
|         DATABASES = { | ||||
|             'default': { | ||||
|                 ... | ||||
|                 'ENGINE': 'localized_fields.db_backend' | ||||
|                 'ENGINE': 'psqlextra.backend' | ||||
|             } | ||||
|         } | ||||
|  | ||||
| @@ -247,34 +247,26 @@ Besides ``LocalizedField``, there's also: | ||||
| Frequently asked questions (FAQ) | ||||
| -------------------------------- | ||||
|  | ||||
| 1. Why do I need to change the database back-end/engine? | ||||
|  | ||||
|     We utilize PostgreSQL's `hstore` data type, which allows you to store key-value pairs in a column.  In order to create `UNIQUE` constraints on specific key, we need to create a special type of index. We could do this without a custom database back-end, but it would require everyone to manually write their migrations. By using a custom database back-end, we added support for this. When changing the `uniqueness` constraint on a `LocalizedField`, our custom database back-end takes care of creating, updating and deleting these constraints/indexes in the database. | ||||
|  | ||||
| 2. I am already using a custom database back-end, can I still use yours? | ||||
|  | ||||
|     Yes. You can set the ``LOCALIZED_FIELDS_DB_BACKEND_BASE`` setting to your current back-end. This will instruct our custom database back-end to inherit from the database back-end you specified. **Warning**: this will only work if the base you specified indirectly inherits from the standard PostgreSQL database back-end. | ||||
|  | ||||
| 3. Does this package work with Python 2? | ||||
| 1. Does this package work with Python 2? | ||||
|  | ||||
|     No. Only Python 3.5 or newer is supported. We're using type hints. These do not work well under older versions of Python. | ||||
|  | ||||
| 4. Does this package work with Django 1.X? | ||||
| 2. Does this package work with Django 1.X? | ||||
|  | ||||
|     No. Only Django 1.10 or newer is supported. This is because we rely on Django's ``HStoreField``. | ||||
|  | ||||
| 5. Does this package come with support for Django Admin? | ||||
| 3. Does this package come with support for Django Admin? | ||||
|  | ||||
|     Yes. Our custom fields come with a special form that will automatically be used in Django Admin if the field is of ``LocalizedField``. | ||||
|  | ||||
| 7. Why should I pick this over any of the other translation packages out there? | ||||
| 4. Why should I pick this over any of the other translation packages out there? | ||||
|  | ||||
|     You should pick whatever you feel comfortable with. This package stores translations in your database without having to have translation tables. It however only works on PostgreSQL. | ||||
|  | ||||
| 8. I am using PostgreSQL <8.4, can I use this? | ||||
| 5. I am using PostgreSQL <9.6, can I use this? | ||||
|  | ||||
|     No. The ``hstore`` data type was introduced in PostgreSQL 8.4. | ||||
|     No. The ``hstore`` data type was introduced in PostgreSQL 9.6. | ||||
|  | ||||
| 9. I am using this package. Can I give you some beer? | ||||
| 6. I am using this package. Can I give you some beer? | ||||
|  | ||||
|     Yes! If you're ever in the area of Cluj-Napoca, Romania, swing by :) | ||||
|   | ||||
		Reference in New Issue
	
	Block a user