I created two classes, Item and Warranty. Item holds a reference to Warranty, and Warranty is tagged with a foreign key attribute. I'm following the same pattern as on the wiki page, yet I keep getting "doesn't know about Warranty" error.
Here's what my classes look like:
Item class
Warranty class
This is what I call to create the tables and the very first line is throwing the error.
OneToOne attribute inherits from Ignore sqlite.net attribute. If your sqlite.net is trying to create the Warranty column is because you have two sqlite.net libraries in your project.
Depending on what SQLite-Net Extensions versions you used, you may have included a different sqlite.net library. Remove your old sqlite-net dependency or use the SQLite-Net Extensions suitable to your current sqlite-net library.
Related
How do a rename a domain class while reverse engineering or after reverse engineering.
i generated class using reverse engineering in Groovy and Grails.
the domain class name was AgentTable. I want to rename it as Agent. When i renamed the domain class using IntelliJ (right click - refactor - rename), it renamed the AgentTable to Agent whereever it was used. but when i start the server (run the app), giving error
"nested exception is org.hibernate.HibernateException: Missing table: agent"
I have to do this for few domain class. is it anyway i can give an alternative name while reverse engineering the domain classes.
or after domain class was created how do i rename it without this error.
Look into your database the name of the table it created for the agent. Once you know the name of the table add the following in your new domain
static mapping = {
table "table-name-here"
}
While it works I would not recommend #elixir 's approach.
In my opinion the mapping is not supposed to be used for renames. This is also how I understand the official documentation.
In the example they use it to map Person onto the 'people' table, not because of a rename but because of a semantic reason. Tables are typically named after the plural form. Here is a nice answer on another question regarding this. In the project I am working on the domain object 'User' is mapped to the table 'users'. You can not use the table name 'user' as it is an SQL statement.
Assumptions and clarifications:
In my experience Grails maps the domain name to the table name after these rules (example domain name 'MyExampleDomain':
separate the domain name by capital letters (My Example Domain)
lower case all (my example domain)
replace spaces with underlines (my_example_domain)
Following this your Domain Class 'AgentTable' has a table 'agent_table' in your respective database. After your rename Grails even tells you what it wants:
nested exception is org.hibernate.HibernateException: Missing table: agent
It wants to look up values in a table called 'agent' but it can not find it. The refactor function of IntelliJ does not rename the functions, so it will miss out on the database.
Luckily we know exactly what values it wants - the values previously found in 'agent_table'.
So why create this confusion with remapping domains and table names when we could just rename the table and be done with it?
The solution:
Execute an SQL script like this on your database:
ALTER TABLE <old_domain_name> RENAME TO <new_domain_name>;
The names are of course in their "table-form".
This simply renames your table to match the expected format in Grails. When restarting everything should be fine.
However you do not need to use rename. You could also create a whole new table, build it the way the domain objects wants it to be and then migrate the data. See section 'Problems with this approach' for information on when to use what.
Problems with this approach:
As always, tinkering with information a program depends on (and even generated itself) will often have some dire consequences if you aren't careful.
For example we have to pay attention to keys. If your domain object has a relation to other objects it will hold them in the table via foreign keys. Depending on how you chose to migrate the information in the table you might have deleted these foreign keys connections. You will have to add them via a separate SQL statement. When you choose to recreate the table this will happen for sure. Renaming it should keep the keys.
Another one are column names. If you choose to rename attributes you will also have to rename the columns via SQL. You will also have to remember the foreign keys other tables might have on the table you are renaming. RENAME did this automatically for me, but you should double check.
Why you should still stick with this approach:
Remapping domain objects to the tables with old names is bound to create code smell and confusion. Do you really want to remember these mappings in your head? And more importantly: do you really expect other people to have to work with this?
The best case is if people can't even tell if this object has ever had a different name and changing the database is the best way I know to achieve this.
Is there a convention for naming Core Data entity? The argument I heard for not prefixing Core Data entity is because there is no chance they will be collision since they only need to be unique within a model, which is not true because the NSManagedObject subclass generated may still collide with existing Objective-C classes.
So it seems logical for me to do two things to Core Data Entity: Prefix it with my project class prefix, and suffix it with Entity. This way, I know it's a Core Data entity, and its name will never collide with any other classes.
I have actually seen both prefixing with the project class prefix and without. I have never seen a suffix being added. I prefer without the project prefix, since if you have a remote database that you are syncing up with, I would use the same entity names. And then if you ever release a public API, do you really want your project prefix all over the place? For example, Stripe's entities are Customer, Card, etc. They use the prefix in the unique identifiers, which I like. Also, if you are using the project prefix for your other classes, you do not run the risk of overwriting, like you mention in your OP.
From here https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html
You cannot give an accessor a name that begins with new. This in turn means that you can’t, for example, declare a property whose name begins with new unless you specify a different getter
And as far as I know also copy keyword cant be used as suffix.
I want to know how you can solve this with ruby on rails:
there is a core module which provides a class BasePlugin.
Optional plugins inherits (single table inheritance) from this base class.
Example: The FooPlugin from fooplugin module is a external, optional module (provided by a third party).
Since STI is used the migrations for FooPlugin need to live in the fooplugin module.
Result: BasePlugin does not know its whole table, since optional external modules add extra columns.
I am new to ruby on rails, but have developed database based applications in different languages for years.
Question:
Is the above usage of STI possible with ruby on rails?
The STI table contains the intersection of all attributes for both the parent model and all children models. Note that in STI, BasePlugin is a model, not a module. External plugins are generally provided as gems.
But the key thing is that BasePlugin doesn't need to have all of it's attributes defined when it is first created. If you later add a FooPlugin child and use a migration to add columns to the base_plugins table to add attributes to FooPlugin, BasePlugin will be able to see those columns. ActiveRecord uses introspection to populate the database columns into the ActiveRecord object at startup, so BasePlugin.attribute_names will show you all columns, even if they are only used by the child type.
Yes you can implement what you describe, as ActiveRecord loads the schema after it connects to the database.
I have written about "best practices" using STI with Rails + ActiveRecord on another stackoverflow question here which might be helpful.
For your use case you will want to make sure plugins don't clash their columns, so you will probably need some kind of column naming scheme/prefix for each plugin.
I no longer use ActiveRecord with Rails, and prefer the more powerful and more performant data access layer Sequel. If you're not locked into ActiveRecord you may want to consider Sequel as an alternative as it supports both STI and also CTI (Class Table Inheritence) as well as the latest Postgres features like JSONB which may be better suited to your use case to keep plugins from clashing with each others columns, or simply just storing your plugin related data in a fully indexed JSON column.
Example: I want to use the interface of nsILocalFile in Javascript, how to find the corresponding Contract ID("#mozilla.org/file/local;1")? Is there a map in the source code?
You don't. This isn't a one-to-one relationship between contracts and interfaces but a many-to-many one:
A single component as accessible by a contract can implement multiple interfaces.
A single interface can have multiple components implementing it and therefore multiple contracts.
But, often it is a one-to-one relationship in practice. E.g. if I wanted to find out about what components implement nsILocalFile, I'd search it in the sources, for instance:
MXR: http://mxr.mozilla.org/mozilla-central/ident?i=nsILocalFile&tree=mozilla-central
A glance over the result list already tells me: line 1255 -- let file = Cc["#mozilla.org/file/local;1"].createInstance(Ci.nsILocalFile);
Else I'd have to look at the files the different results link, starting with the .js ones.
Other times, the contract ids are even specified in the idl itself, e.g. in nsITimer.idl (at the bottom).
The most commonly used interfaces usually are also present on MDN incl. contracts, e.g. nsILocalFile.
I would like to extend the types generated by the LinqToSQL TypeProvider with additional members. Is this possible? For example if the TypeProvider is pointed to a DB with a table called Company it will expose a type Company with access to the columns. As an example can I a member Company.employees to the generated type which will return all current employees from the employees table?
I don't see why you could not.. provided you have the source for the type provider!
That said, creating or extending a type provider, while not being overly complicated, is not trivial either.
So depending on how central this type generation aspect is for you, it might be best to use existing type providers, and build a layer on top of them on the 'client side'.
Once you have refined a compelling scenario where this would really yield value, then you can reuse this layer anyway.
What is your end-scenario ?
Doesn't the existing SQL Type provider cover the Company.employees case ?
It sounds like what you want to do could be accomplished by using a type extension.
Type extensions can be added to any accessible type, which should include types generated by the type provider.